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Abstract. Recent mainstream programming languages such as Erlang or Scala 
have renewed the interest on the Actor model of concurrency. However, the lit- 
erature on the static analysis of actor systems is still lacking of mature formal 
methods. In this paper we present a minimal actor calculus that takes as primitive 
the basic constructs of Scala's Actors API. More precisely, actors can send asyn- 
chronous messages, process received messages according to a pattern matching 
mechanism, and dynamically create new actors, whose scope can be extruded by 
passing actor names as message parameters. Drawing inspiration from the linear 
types and session type theories developed for process calculi, we put forward a 
behavioural type system that addresses the key issues of an actor calculus. We 
then study a safety property dealing with the determinism of finite actor com- 
munication. More precisely, we show that well typed and balanced actor systems 
are (i) deadlock-free and (ii) any message will eventually be handled by the target 
actor, and dually no actor will indefinitely wait for an expected message. 

1 Introduction 

Recent mainstream programming languages such as Erlang or Scala have renewed the 
interest on the Actor model ( H10I3I ) of concurrent and distributed systems. In the Ac- 
tor model a program is an ensemble of autonomous computing entities communicat- 
ing through asynchronous message passing. Compared to shared-state concurrent pro- 
cesses, the Actor model more easily avoids concurrency hazards such as data races and 
deadlocks, possibly at the cost of augmenting the communication overhead. On the 
other hand, compared to the channel-based communication of process calculi such as 
the 71-calculus or the Join-calculus, the actor abstraction better fits the object oriented 
paradigm found in mainstream programming languages. 

Actors can send asynchronous messages, process received messages according to a 
pattern matching mechanism and dynamically create new actors, whose scope can be 
extruded by passing actor names as message parameters. The Actor model and the asyn- 
chronous process calculi then share similarities such as (bound) name passing, but they 
have also many differences: actors have an identity (a name), they are single threaded 
and they communicate by sending messages to the mailbox of other actors rather than 
using channels. Despite their similarities, while a rich literature on type-based formal 
methods has been developed for the static analysis of process calculi, few works deal 
with the Actor model (see Section|4]for a discussion of the related work). In this paper 
we study a minimal actor calculus, AC, with the aim of bringing in the context of Actors 
the successful techniques developed for process calculi. 

More precisely, drawing inspiration from the linear types and session type theo- 
ries developed for process calculi ( 01611 1113181 ), we put forward a type system that 



addresses the key issues of an actor calculus. Programming an actor system entails the 
design of a communication protocol that involves a (dynamic) set of actors; we then 
study a behavioural type system for AC where actor types encode the intended com- 
munication protocol, and the type checking phase statically guarantees that runtime 
computation correctly implements that protocol. Moreover, we study a safety property 
dealing with the determinism of actor communication, so that in well typed and bal- 
anced actor systems any message will eventually be processed by the target actor, and 
viceversa, no actor will indefinitely wait for an expected message. Dealing only with 
finite computation, we devise a simple technique to let types also prevent deadlocks. 

Even if AC only considers actors with finite computation, which is clearly a strong 
limitation, proving that a finite system complies with the intended communication pro- 
tocol is not trivial, since nondeterminism, fresh actor name passing and the asynchronous 
semantics of the underlying model complicate the picture. As we said, our behavioural 
type system is reminiscent of the type discipline of linear and session types. However, 
even if the actor calculus shares with session types the idea of conceiving the computa- 
tion as the implementation of a specified communication protocol, there are a number of 
key differences between the two models (see Section|4]i. In [1411 session types are added 
to a Erlang-style core actor calculus. However, in that paper session types appears an 
orthogonal feature of the actor language, while we aim at showing in this paper that 
the reasoning underlying session types is in some sense inherent to the Actor model. 
As a general comment that can guide the reader through the technical part of the paper, 
one can think that session types describe the flow of communications withing a single 
conversation session. Instead, an actor's behavioural type takes the point of view of an 
entity that might concurrently participate to different (interleaved) conversations with 
different parties. 

2 The Actor Calculus 

We assume a countable set of actor names and a countable set of variables, ranged over 
by a, b,c and x,y respectively. Identifiers, denoted with u, rage over names and variables. 
We reserve the letter m to range over a distinct set of message labels. The syntax of the 
Actor calculus AC comes from the basic constructs of Scala's Actors API 115191 : 

Expressions e ::= | u \m(u);e | reactlm^x,) e,'},<=/ | vala = actor{e};e 

The expression u\ \m{u2)\e sends to the actor u\ the message m with the tuple of ac- 
tual parameters Ui, and then continues as e. According to the Actor model, sending a 
message is an asynchronous action that just adds the message miu-i) into the mailbox 
associated to the actor u\. Message handling is carried over by the react expression, 
that suspends the execution of the actor until it receives a message ntj e When 
a matching message is found in the actor mailbox, the execution is resumed and the 
corresponding continuation is activated. 

New actors are dynamically created with expression vala = actor{ei};e2, that cor- 
responds to the inline Scala primitive for actor creation. It defines and starts a new actor 
with name a and body e\ and then continues as ei- The actor definition introduces a 
new, bound, name a whose scope is both the new actor's code e\ and the continuation 



e2- In order to have a uniform semantics, we assume that a program is a top level se- 
quence of actor definitions, while input and output expressions can only occur inside an 
actor body. This is not restrictive since it would be sufficient to assume an implicit main 
actor containing the top level sequence of expressions. Anyway, observe that besides 
the top level definitions, new actors can still be dynamically spawned by other actors 
anytime during the computation. 

The execution of a program spawns a bunch of concurrent actors that interact by 
message passing. Therefore programs are represented runtime by configurations: 

Configurations F :: = | [a i— >M]a{e} \ F\F | (ya)F \ e 

(va)F is a configuration where a is a private actor name. While each actor is single 
threaded, a configuration is a parallel composition of a number of active actors and an 
expression e containing the residual sequence of top level actor definitions. An active 
actor a is represented runtime by [a i— > M] a{e}, where e is the residual body of the 
actor and [a i-> M] is its associated mailbox. Mailboxes are lists of received messages 
of the form [a H> m\ (b\ ) • . . . • nikipk)]- Message parameters are values (i.e. actor names) 
since, according to Scala semantics, message parameters are called by value as they are 
implemented as parameters of an Actor object's method invocation ( |fl31 ). 

Definition 1 (Free Names and Well Formed Configurations). In input expressions 
formal parameters are bound variables, and actor definitions act as name binders. We 
work with well formed configurations where any bound name and variable is assumed to 
be distinct (Barendregt's convention), and where in any input branching react {mi(xi) 
e,},G/ the labels nij are pairwise distinct. 

The operational semantics is given in FigureQ] Most of the rules come directly from 
the ft-calculus. The rule (Ended) states that a terminated actor a with no pending mes- 
sage in its mailbox can be garbage collected. The rules (TOP SPAWN) and (Spawn) are 
used to spawn a new actor respectively from the top level main thread and from another 
actor. In both cases the new actor is activated by extending the configuration with a 
new empty mailbox and an additional thread running the body of the new actor. The 
rules (Send) and (Receive) implement the Actor communication model: an output 
expression adds a message to the mailbox of the target actor, while an input expression 
scans the mailbox for a matching message. Notice that the mailbox is not handled as 
an ordered queue of messages, hence for instance, the configuration (where we omit 
message parameters) 

[b i-^ 0] a{b \m\\b ! m2',Q} | [b h-» 0] b{ react {m\ => react{m2 => e}, 

m2 =>■ reactjmi =>■ e'}}} 

nondeterministically reduces either to [b M> 0]b{e} or to [b i— > 0]b{e'}. In other words, 
besides being asynchronous, in the Actor model the ordering of outputs is not guaran- 
teed to be mirrored by the ordering of input handlers, which is instead the case of, e.g., 
asynchronous session types with buffered channels 118161 . 

Example 2. The following program defines two actors that meet in a three-way hand- 
shake. The actor b starts by sending a ping message to a, then waits for a pong message 
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Fig. 1. Operational semantics 

that carries the name of the actor to which it sends the final pang message. The actor a 
performs the dual sequence of actions. 

Pr = val a = actor{react{p/ng(x) => x I pong(a); react{pang() =>• 0}}} ; 
va\b = actorja ! ping(b); react{pong(y) =>■ y ! pang();Q}} ; 

Now consider the case where the actor Alice starts two sessions of this protocol to 
interact both with Bob and Carl (Figure |2). In order to prevent interferences between 
the two sessions, a couple of private sub-actors are established for each protocol session. 
This is similar to private sessions in the ft-calculus. 

Alice { valab = actor {react{dest(y) => P{y)}} \ Bob ! new(ab) ; 

valac = actor{react{<ie5f(y) P{y)}} ; Carl ! new(ac) ; } 
Bob { react{new(z) \ia\ba = actor{Q(z)};z ] -dest(ba);Q} } | 
Carl { react{new(z) =>• valca = actor{Q(z)};z \dest(ca);0} } 

where P(y) = y ! ping.react{pong =>• y ! pa«g;0} and 
Q(z) = react{ping => z ! pong .react{pang => 0}}. 
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Fig. 2. Examples 

Example 3. We can rephrase in the actor calculus a simple example of multiparty com- 
munication protocol that captures the interactions in a purchase system (Figure|2]i: 

Buyer{Seller\buy{Buyer 1 item); react{price(z) react{details(w) => •■•}}} i 

Seller{ react{ buy(x,y) =>■ x ! price{f(y)); 

val Shipper = actor{reacX.{ship{x 1 y) =$-x\details(f(y)); ...}}; 
Ship perl ship(x,y); ...}; 

A Buyer actor sends to the Seller actor its name together with the item he wants to 
buy, and waits for the price and the shipping details. Dually, the Seller handles the buy 
message by sending to the Buyer the price f(item) of the selected item and spawns a 
new Shipper actor that directly interacts with the Buyer to finalize the shipping. Observe 
that the Buyer actor needs not to be aware that he is actually interacting not only with 
the Seller but also with a (restricted) Shipper. This is a further difference with the case 
of multiparty session types, where each interacting party is identified by its endpoint of 
the session channel. 

3 The Type System 

We assign behavioural types to actor names so that a type describes the sequence of 
inputs and outputs performed by the actor body. Moreover, inputs are handled as linear 
resources, so that to guarantee that for each expected input there is exactly one matching 
output. We use the following syntax for the types associated to actor names, where 
NoMark(5') means that S does not contain any marking: 

Types T ::= [5] 5 ::= end | \m(T).S \ & ieI {7m i (T i ).S i } 

| &* G/ {*?m(f ).S, 7mi{fi).Si} with NoMark(5,) V/ £ / 

Types T are finite sequences of input and output actions. Output action \m(T) is the 
type of an output expression that sends the message m with a tuple of parameters of type 



t . Dually, the input action (7)). S,} offers the choice of receiving one of the 

messages m, and continuing with the sequence 5,-. Differently from session types, we do 
not consider output choices. Indeed our aim is not to provide an expressive calculus for 
protocol specification, but to put forward a type based technique to statically verify the 
protocol conformance of actors. On the other hand, it would not be difficult to extend the 
type system with output selection ©,<=/{ ! mj(*).S,-} along the lines of input branches. 

The type system then makes use of linear type assumptions to guarantee that each in- 
put is eventually matched by exactly one output in the system. Linear type assumptions 
are handled by means of markings. The marked action &' eI {"lm(T).S, ?m,(7/).5' 1 } 
pinpoints an input that is "consumed" by one output expression. To illustrate, the actor 
a{blm(c)} is well typed assuming a:[\m(T).S a ], b:["!m(T).Sb) since a consumes b's 
input. On the other hand the actor b{react{m(x) e}} is well typed assuming the non 
marked type b : [fm(T).Sb], since b offers an input without consuming it. Moreover, 
to deal with branching inputs we have to ensure that all the messages eventually re- 
ceived by an actor belong to the same branch of computation. For instance, consider 
the actor a : [& {?mi.?m2, Im^.lm^]] (where we omit message parameters), then the 
actor b{a \ m\\a \ rri4} is incorrect since it sends to a two messages belonging to alter- 
native execution paths. Indeed, the typing of b would require for a the type assumption 
a : [&*{*?mi.?ra2, Im^.'lm^], which is prohibited by our syntax of types since it con- 
tains two markings in two different branches. 

Another key point is the parallel composition of type assumptions, that must be 
defined so that to ensure the linear usage of marked inputs. To illustrate, given the type 
of the actor a above, the parallel composition b{a ! m\ } c{a ! m^} must be prohibited 
since only one of the two messages will be handled by a while the other one will stay 
pending in a's mailbox. In other terms, the two outputs compete for the same "input 
resource". Notice that the typing of b, resp. c, would require the assumption a : T a = 
[&*{*?mi.?OT2, ?OT3.?OT4}], resp. a:T^ = [& , {?mi.?ra2, 'Im^.lm^}. The fact that the 
same input choice is marked both in T} t and T t f indicates that b and c consume the same 
input choice, hence they cannot be composed in parallel. 

More formally, we define a merge-mark function that is used to linearly compose 
type assumptions. More precisely, parallel threads must assume the same type assump- 
tions but with disjoint markings. 

Definition 4 (Merge-Mark). Let S, S' be two sequences that are equal but for the mark- 
ings. Then [S] 1+) [S'] = [S ttl S'] where the partial function tfcl is defined by 

end l±) end = end \m(f ).5W !m(f ).S' = !m(f ).(SWS") 

& ieI {?,n i (T i ).S i }tt& ieI {?m i (T i ).S' i } = & ieI {7m i (T i ).(S i <SS' i )} 
& ieI {lm(f)S,lm i (f i )S i }^&J el {'7m(f)S',7m i (f i ).S i } = 

= &^ 1 {'7m(T).(S^S l ),7m i (T i ).S i } 

The main clause is the last one, together with the symmetric one that we omit. A marked 
input can only be merged with a corresponding non marked input, and merging recur- 
sively applies only to the marked branch. In this way we ensure that the same input 
choice is consumed by exactly one output, and that further outputs only consume inputs 
belonging to the same branch of computation. 



A type environment T is a partial function assigning types to names and variables. 
We use for F the list notation. Let be Fi , F2 two type environments such that Dom{F\ ) = 
Dom{F2), then we denote by F\ WT2 the type environment obtained by merging the 
markings contained in the two environments, i.e., F\\+)F2 = {u '■ Fi(u) WI^m) | u 6 
Dom{F\) = Dom(F2)}- We use the notation F;a : T for environment update, that is 
F\{a:F(a)}U{a:T}. 

So far so good, however this is not enough since the scope extrusion mechanism 
obtained by passing fresh actor names as message parameters raises additional is- 
sues. Consider the actor a{react{foo(x) => xlm(a)}}, a consumes the m input of- 
fered by some actor which will be dynamically substituted for the bound variable x. 
In order to statically collect the resources consumed by a, the typing of a must as- 
sume for x the marked type [*?m(r).end]. A similar situation applies when new ac- 
tors are spawned. For instance, consider the previous actor a in parallel with c{va\b = 
actor{react{m(v) => e}};a If 00(b)}. The parameter x of the foo message is substi- 
tuted with the fresh actor name b. Hence in order to check that every input in the 
system is consumed, besides the type of x, we must record the type of the fresh ac- 
tor b : [lm(T). end] and devise a way of matching the input "consumed" in x with that 
"offered" by b. 

We then rely on type judgements of the form rhf> A, where F collects the type 
assumptions about free names and variables of F, while A collects type assumptions 
on bound names and bound variables of F . Observe that working under Barendregt's 
convention on bound names/variables, we avoid name conflicts. We call A the escape 
environment, and we let it preserve the branching structure of the computation where 
alternative continuations can be activated when an input choice is resolved. 

Definition 5 (Escape Envirnoment). The escape environment A is a choice between 
alternative type environments defined by A ::= &, G /r,- | &,e/A,, where Dom(Fi) PI 
Dom(Fj) = and Dom(Aj) nDom(Aj) = for i,j E I. 

We use the following notation for escape environment extension: (&, e /A,), u : T = 
& ie i {Ai,u:T), and (& jeJ Aj) , (&; € /A,-) = & iG7 &, e/ (A/, A,). 

3.1 Typing Rules 

The main judgement of the type system is r h F>A. It means that the actors in F 
execute the sequence of actions described by their type and the marked input actions in 
r and A are exactly those that are consumed by the actors in F. Moreover, Dom(F) n 
Dom(A) = and fn(F) C Dom(F) while bn(F) C Dom(A). We also use additional 
judgements: r h o states that F is well formed (according to standard rules given in 
Figure |3), F\- a :T states that the actor a has type T in F, and r h [a i-> M] states that 
the mailbox only contains messages that are well typed according to the type that F 
assigns to a. Finally, T h„ e > A states that e is well typed as the body of the actor a. 

Type rules for actors. The rule (Type Spawn) applies when the actor a spawns a new 
actor b. The type assumptions are split between those used by the continuation of a's 
body e2, and those used by the body of the new actor e\. The same holds for escape 
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(Type Receive) (Type End) 
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r h fl react {m,-(f ,■) => <?,} fe/ > & i6/ (A ; , {x,- : 7-}) T h fl 0> 

Fig. 3. Type Rules for Actors 



assumptions, which collect the resources offered and consumed by bound names and 
variables in e\ and e 2 - The name b of the new actor must be fresh, and a type for b 
must be guessed. Since the scope of b includes both e\ and e%, both expressions are 
typed under a suitable assumption for b. S\ must correctly describe the sequences of 
actions performed by b's body e\. Moreover, S\ must contain marked input actions that 
correspond to the input offered by b and locally consumed by messages sent by /?'s body 
to b itself. On the other hand, the marked inputs in 5 2 must correspond to the messages 
sent to b in e 2 . In the conclusion of the rule the escape environment globally collects 
the type assumptions locally used for b, hence Si W 5 2 must be defined, that is Si and S 2 
must be the same sequence of actions with disjoint markings. 
Accordingly to (Type Send), when a sends the message m(u') to the actor u: 

1 . the first action in the type of a is the output of m; 

2. the type of u contains the input of m as a marked input. The matching input needs 
not to be the first action in the type of u. This allows for instance that even if u 
accepts a foo message before m, the actor a is free to first output u ! m and then 
u Ifoo, according to the semantics of AC. 

3. The continuation e is typed in an updated environment where the marking of the 
matching input has disappeared from the type of u to record the fact that the re- 
source has been already consumed. Moreover the type of a is updated to the con- 
tinuation type [S a ] to record that the output action has been already performed. 
Observe that this implies that the behavioural type assumed for an actor changes 
(decreases) as long as the actor advances in its computation. 



As far as the typing of the message parameters are concerned, let first introduce some 
notation: given two sequences S and S', we write S « S' when S is a suffix of S' inde- 
pendently of the markings (see AppendixlAlfor the formal definition). Given the output 
u ! ot(m'), it might not be the case that the actual parameters u 1 have the types of the for- 
mal parameters f. Since the type of an actor decreases as long as the actor computes, 
in the asynchronous semantics the type of an actual parameter u' at sending time can 
be different from (longer than) the type u' has when u processes the message. Then 
the type of a formal parameter T is in general a suffix of the type T(u'). Moreover, the 
marked inputs contained in T(u') are those that are consumed by the body of a, while the 
markings contained in T correspond to the inputs offered by the formal parameter and 
consumed by the actor that receives the message, that in general is not a. Summing up, 
the rule (Type Send) requires (each type in the tuple) T to be a suffix of r(S') (com- 
ponentwise), independently of the marked actions. A stronger requirement is needed 
when a parameter of the message coincides with the sender a, resp. the receiver u. In 
these cases the type of that formal parameter must be a suffix of the residual type of a 
after the output, resp. the residual type of u after the input. The rule uses the following 
predicate (componentwise extended to tuples of types), where we call T(u') \_ m the type 
of u' "after m": 

T « r(it') [m= if «' = a then T « [S a ] 

else if u' = u then T « [S] else T « T(u') 

To type an input expression the rule (Type Receive) requires the type of a to indi- 
cate that the next action is a non marked matching input action, and every continuation 
e,- to be well typed in the type environment where the type of a has advanced to [5,-] and 
the formal parameters i, have been added. Observe that if the input action were marked 
in the type of a, it would mean that the input is consumed by the continuation e,, which 
would result in a deadlock, as in, e.g., a{react{ra => a ! m}}. Finally, the names and the 
types of the formal parameters are recorded in the escape environment of the conclusion 
of the rule, preserving the branching structure of the computation. 

According to the rule (Type End), the expression is well typed assuming that 
the type of a contains no more actions. Moreover, F must contain no marked input: a 
judgement like T,b : [*?m(T).5] h fl 0> would mean that the typing of the body of a 
has assumed to consume the input of b, but it is not the case since the body is terminated 
but the action ?m of b is still marked. 

Type rules for Configurations. Rule (Type Res CONF) shows that when a new name 
is introduced, a corresponding type must be guessed. The new name is local to the 
configuration F, but it is globally collected in the escape environment. The rule requires 
a to be fresh in A, but the derivability of the judgement in hypothesis implies that r, a : T 
is well formed, hence a £ Dom(F). 

In order to type an active actor, the rule (Type Actor) requires the (residual) actor 
body e to comply with the (residual) sequence of actions in T(a). Moreover, the mailbox 
[a H» M] contains the list of messages M that have been received but not handled yet 
by the actor a. A message in M will be processed by the actor only if the type T(a) 
contains a matching input action. The rule (Type Mailbox) does not require that 
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Fig. 4. Type Rules for Configurations 



every message has a corresponding handler in T(a). However, we show in the following 
that in well typed systems mailboxes only contain messages that will eventually be 
handled by the receiving actor. Let Inputs([S]) be the set of top level input actions 
contained in S. Then the rule (Type Mailbox) states that if a message in the mailbox 
corresponds to one of the receivable inputs, then the type of the formal parameter is 
a suffix of the type that F assigns to the actual parameter. The notation T « T(y) [ m 
means that if v = a then T « S else T « T(v), and it is extended to tuples of types as 
expected. 

The rules (Type Dead) and (Type Top Spawn) are similar to the corresponding 
rules for actors, hence we reserve a final discussion for the rule (Type Para) for par- 
allel composition. The rule (Type Para) splits the type environment and the escape 
environment so that to ensure that the resources consumed by F\ \ F 2 are consumed 
either by F\ or by F 2 . To illustrate, consider 



In order to correctly compose the two actors in parallel, the marked actions in T a , resp 
Tb, must be disjoint form those in T' a , resp. T' h . Moreover, since in the typing of an active 
actor the behavioural type of the actor can be a suffix of the initial type of that actor, we 
have that T a « T' a and Tl « 7j. Hence the merge-mark function W must be extended 
so to compose a sequence with a subsequence of actions. Let S' <± S be a partial function 
defined as S' W S plus the following two cases, that apply when 5' is a proper suffix of S: 



S' <± & ieI {lm i {f i ).S i } = & iel \ {j} {lm i (f i ).S i , lmj(fj).(S' <£ Sj)} if 5' « Sj 



a : T ai b: T h ,... h [a^M]a{e}t> A 



a : T^,b:Tl,... h [b ^ M']b{e'}> A' 



S'<±lm(T).S= \m(f).(S' <±S) 



if S' «S 



In particular we let be undefined the case S' <± &* G/ {*?m(f).5, ?»i,-(7/).S/}. Indeed, if 
T a = [S 1 ] and T' a = [&' e] {"lm(T).S, ?m,-(7}).5/}], it means that the actor b sends the 
message m to a but the corresponding input handler is not in the body of a anymore. 
Hence, a type with a marked action must be composed with a type containing the same 
non-marked action, so that to ensure that the input "consumed" by a thread is actually 
"offered" by a parallel thread. The type environment composition is defined as follows: 



(r lr Fj©r 2 ,F 2 )( M ) = 



' T2(u) ttfTi (m) if u <£ actors(Fi) Uactors(F2) 
Ti(u) <±T2(u) if u £ actors(Fi) 
^l{u) GE T\(u) if u £ actors^) 

where actors(/ r ) collects the free names of active actors in F (see Appendix [At. 

Example 6. Consider the program Pr in Example [2] We have that h Pr > {a : ?y 1+1 
T a 2 , b :Ti,, x : T x , y : T v }, which comes from the following two judgements where e a , 
resp. e^, is the body of the actor a, resp. b: 

a : \- a e a > {x : rj a : T 2 , b:T h \- h e h > {y : T v } 

r„' = [?ping(T x ). \ pong (T y ).l pang. end] T x = ['lpong(T y ). \pang.end] 
T a = ["?ping(T x ). ! pong (T y ).l pang. end] r v = [*?/?a«g.end] 
r 6 = [\ ping (T x ).l pong (T y ). \ pang. end] 

Preventing deadlocks. The type system described so far is enough to prove that actor 
implementations comply with the prescribed protocol, however program execution may 
stuck in a deadlock state, as for the program P = val a = actorjval b = actor{react{« =>■ 
a I to}} ; reactjro =>• bin}} which is so that 

P — > [a i ^ 0]a{react{m ^>b\n}} \ [b H> 0]^{react{7i aim}} 

In order to prevent deadlocks we propose a simple technique that nicely copes with fi- 
nite actor computation. We add more structure to types: we modify the syntax of types 
so to have output actions of the form T ! m(T).S, where the additional component T de- 
scribes the sequence of actions performed by the target actor after processing the mes- 
sage m. For instance, a : [[Sb] ! m(r).end] is the type of an actor a that sends the message 
m to an actor that eventually reads the message m and then continues as described by 
Si,. Let b be the target of such a message, and let be b : [S.lm(T).Sb\. In asynchronous 
communication, when a delivers the message to b, it cannot know when b will process 
such a message, but it can safely assume that after the input of m, b will continue as Sb- 
Adding such a piece of information into types is enough to disallow deadlocks. Indeed, 
the typing of the program P above requires (overlooking the markings) the assumptions 
a : \lm.T' ! n.end],b : [In.T" !m.end], that are not well defined since T' and T" can only 
be mutual recursively defined: T' = [T" ! m.end] and T" = [T' I n.end]. In other terms, 
there are no (finite) types so that P is well typed. 

It turns out that the refinement of types leaves unchanged most of the type rules pre- 
sented above. We only have to do a couple of modifications. First, the type assumption 
for the actor a in the rule (Type Send) must be Y h a[[S'} ! m{T).S a ], with S' equal to S 



but for the markings. That is we add to the output action the sequence S indicated in the 
type of the target actor u as the continuation after the input of m. Then we have to adapt 
the relations between types that we introduced: W, resp. <± , are obtained by adapting the 
clauses dealing with output actions, i.e., T ! m(T) .S W T ! m(T) .S' = T \m{T ).(StfclS'), 
resp. S' <± T\m(f).S = T ! m(f).(S' S S). 

3.2 Properties of the Type System 

We show that the type system respects the semantics of AC, i.e., well typed config- 
urations reduce to well typed configurations. However, since actor types decrease as 
long as the computation proceeds, the subject reduction theorem relies on the following 
notion of environment consumption. 

Definition 7 (Environment Consumption). 

- We write T' « T when Dom(T) = Dom(T') and Vm G Dom(Y), T' («) = [S'] ,T{u) = 
[S] such that S' « S. 

- A' « A when A = &, G /r,-, A' = & jeJ T'j with J CI, Y' } C Tj andMu G Dom(T'j) , Vj G 
/. T'j(u) «Tj(u). 

The substitution lemma allows a name b to be substituted for a variable x. In the 
lemma the type of x is assumed to be a suffix of the type of b, and when x is unified with 
b, the markings assumed for b must be updated so that they also contain those assumed 
for x. With an abuse of notation, when 5' « S we let S' WSbe defined as S' <± S plus the 
clause S'&&t eI {"!m(T).S, ?m,(7-).5 / } = &* G/ {*?m(r).(5 / WS 1 ), ?m ; (7}).S;, }, that were 
forbidden in the composition of parallel threads. Such a clause here is not a problem 
since the substitution lemma applies within a single thread, i.e. within the body of an 
actor at the moment of receiving an input, where it is safe to merge local assumptions. 

Lemma 8 (Substitution). Let be F,x : T h„ e > A 

- let c be an actor name s.t. a =/= c and T « T(c), then T,c : T\£T(c) h a e{ c '/., } > A; 

- let be ?m(T).5 G Input (T(a)) such that T « [S], then T;a:T ti)T(a) \~ a e{ a / x }> A. 

Theorem 9 (Subject Reduction). IfT h F > A and F — > F', then there exist T' such 
that T' h F' > A', w/f/i T' « T a«<i A' « A. 

Let F be a well typed closed system, i.e. 0hf > A. We have that any input action 
that is marked in A exactly corresponds to one output expression in F that eventually 
consumes that input. We say that a well typed actor system is balanced whenever every 
input in the system appears marked in the escape environment. As a consequence, in 
balanced systems every input has a matching output and viceversa. Then (finite) bal- 
anced systems eventually terminate in the empty configuration, correctly implementing 
the communication protocol defined by the typing. 

The definition of balanced environment checks that every actor has a fully marked 
type, possibly with the contribution of the markings contained in the types of a number 
of variables. Indeed, since actor names are passed as parameters, the inputs offered 
by an actor a can be consumed by outputs directed to variables that are dynamically 



substituted with a, as in b{react{foo(x) => x\m}} \ a{b ! /00(a); react{ra => e}}. Let 
be fullmrk([S]) = [5'] where S ! and S are the same sequence of actions, but in S' every 
top level input is marked. 

Definition 10 (Balanced environment). We write balanced (A) when 

- ifA = {x x :Ti,...,x n :T n } then NoMark(ri), . . . NoMark(7;); 

- if A = {ui ■ T\ , . . . , u„ : T n }, then for any name a G Dom(A) 

1. 3 xi, ...,Xk G Dom{A) such that A(a) = T, A(x,) = 7} with 7] « T and ((T 1+1 
7i)a... \£T k ) =fullmrk(T) 

2. balanced(A\ {a : T,x\ : T\,...,Xk : 7a}); 

- if A = Scj^iTj, then balanced(r,)/or any i G 7. 

Observe that the escape environment in Example|6]is balanced. Indeed we have that A = 
{a:T^T^, b:T b , x:T x , y:T y },A(y) «A(a) and A(y) WA(a) =fullmrk(A(a)). Similarly, 
A(x) « A(b) and A(jc) W A(i) = fullmrk(A(fe)). 

Let — s>* be the transitive closure of — A final lemma shows that during the com- 
putation of well typed actor systems mailboxes only contain messages that are eventu- 
ally handled by the receiving actor. 

Lemma 11. If0\-Pr> AandPr — >* (va\, ..,ak)([a ^ M]a{e] \ F), then there exists 
r such that r h [a i-> M]a{e} and for any m(v) G M, there exists a matching input action 
!m(T).S that belongs to Inputs(T(a)). 

Theorem 12 (Safety). 7/0 h Pr> A with balanced(A). IfPr — >* F then either F = 
or F — ► F' for some F' . 

Example 13. Consider the program Pr. 

vala = actor{react{/?;ng(x) => x ! pong(se\f); react{pang() => 0}}} ; 
va\b = actorja ! ping(se\f); react{pong(y) 0}} ; 

It is easy to see that Pr — >* [a h-> 0] a{react{pang() =>■ 0}} | -f-^r since there is 
no actor sending the message that a is waiting for. Nevertheless, the program can be 
typed, but with an escape environment that is not balanced. Indeed, h Pr > A is 
derivable with A = {a : ['?ping(T x ).T*] t b : [T* ! ping(T x ) .? pong([? pang .end]) .end], x : 
T x =['lpong([7pang.end]).end], y: [Ipang.end] } where T* = [[end] ! pong([l 'pang. end]). .? pang. end]. 
Then the communications are well typed but the fact that in A there is no mark for the 
input Ipang shows that the program does not consume that resource, as indeed the 
operational semantics above has shown. 

Example 14. As a final example observe that the deadlock program discussed above, 
that is P = vala = actor{val£> = actor{react{n => a\m}}; reactjm => bin}}, is bal- 
anced since a's input is matched by Z?'s output and viceversa. However, the program 
stucks in a deadlock and indeed it is not well typed, according to the safety theorem. 



4 Conclusions and Related Work 



We presented AC, a core actor calculus designed around the basic primitives of the 
Scala's Actors API, together with a behavioural type system and a safety property deal- 
ing with the determinism of finite actor communications. We think that this work sheds 
light on how formal methods developed in the context of linear types and session types 
for the 7t-calculus can be profitably reused for the analysis of actor systems. 

As we pointed out in the Introduction, our type system draws inspiration from the 
formal methods developed in the contexts of linear types and session types for pro- 
cess algebras ( 111611 1113181 ). Indeed, the Actor programming model shares with session 
types the idea of conceiving the computation as the implementation of a specified com- 
munication protocol. However, there are a number of key differences between the two 
models. First, in asynchronous session types ( 118161 ) two sequential outputs are (asyn- 
chronously) processed according to the sending order, while if an actor a sends two 
messages to the actor b, i.e. a{b\m\\b\m.2}, then b is free to read/process the second 
message before reading/processing the first one, i.e. &{react{w2 => react {to i => ...}}}. 
This means that in the Actor model we have to deal with looser assumptions, in that 
we cannot look at the order of input, resp. output, actions to infer something about the 
order of the dual output, resp. input actions. More importantly, in multiparty session 
types ( 112171 ) the set of interacting parties (or the set of interacting roles) in a given ses- 
sion is known from the beginning, while an actor system is a dynamic set of interacting 
parties. In particular, since new actors can be created and actor names can be passed 
as parameters, the communication capabilities of actors dynamically increase, in a way 
similar to the scope extrusion phenomenon of the ft-calculus. 

Intuitively, session types describe the flow of communications withing a single con- 
versation session. An actor's behavioural type instead takes the point of view of an 
entity that concurrently participates to different (interleaved) conversations with differ- 
ent parties. In this sense the Actor model share some similarities with the Conversation 
Calculus II 17141 CC, where processes concurrently participate to multiparty conversa- 
tions and conversation context identities can be passed around to allow participants 
to dynamically join conversations. The Conversation Calculus is designed to model 
service-oriented computation, and it is centered around the notion of conversation con- 
text, which is a medium where related interactions take place. The main difference with 
the Actor model is that in CC named entities are the conversation contexts, while named 
actors are the conversant parties. Hence the powerful type system in |4 | associates types 
to conversations rather than to actors. 

To he best of our knowledge, there are few works dealing with type systems for Ac- 
tor calculi. In the Actor model is encodes in a typed variant of the 71-calculus, where 
types are used to ensure uniqueness of actor names and freshness of names of newly 
created actors. The work in J5] study a type system for a primitive actor calculus, called 
CAP, which is essentially a calculus of concurrent objects a la Abadi and Cardelli jT) 
where actors are objects that dynamically, that is in response to method invocation, 
change the set of available methods. Such a dynamic behaviour may lead to so called 
"orphan messages" which may not be handled by the the target actor in some execution 
path. In order to avoid such orphan messages, a type system is proposed so to provide a 
safe abstraction of the execution branches. Finally, In flT4l a concurrent fragment of the 



Erlang language is enriched with sessions and session types. The safety property guar- 
anteed by the typing is that all within-session messages have a chance of being received 
and sending and receiving follows the patterns prescribed by types. In our work we fol- 
lowed a different approach: instead of adding sessions to an actor calculus, we reused 
session type techniques to deal with the communication model distinctive of Actors. 

As for future work we plan to extend the AC calculus to deal with recursive actors. 
Infinite computation requires a different formulation of the safety property, since com- 
pliance with the intended protocol does not reduces anymore to the termination of all 
actors with empty mailboxes. Moreover, deadlock freedom requires more sophisticated 
techniques, such as those in H6I4I that are based on a proof system that identifies cyclic 
dependencies between actions. 

Acknowledgements. The author is indebted to Mariangiola Dezani-Ciancaglini and 
Luca Padovani for insightful discussions about session type theories. 
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A Notation and Useful Definitions 



Let &° £f {?m i (7i).Si} stands for an input action, either marked or not. 

Definition 15 (Suffix). Let S andS' be two sequences of actions, we write S « S' when 
S is a suffix of S' according to the following rules: 

S«S' S«Sj 3iel 

end«S S«S S«T\m(T').S' S « &? 6/ {?m i (7/). > S I } 

Definition 16 (Inputs). The set of top level inputs contained in a type T, written Inputs(T), 
is defined as follows: 

Inputs{[T\m(T').S]) =Inputs([S]) 

Inputs([&'? eI {°7m i (T i ).Si}]) = U i€ /{?m / (7-).5,}U/np^([S;]) 
Inputs([end}) = 

Definition 17 (Free active actors). The set actors(F) of free active actors in the con- 
figuration F is defined as follows: 

actors(O) = actors(e) = actors([a ^> M]a{e}) = {a} 

actors(,Fi | F2) = actors(Fi) Uactors(,F 2 ) actors((va)/ r ) = actors(F) \ {a} 

B Proof Sketches 

Substitution Lemma Let be F,x : T \- a e > A with x =/= a, 

- let c be an actor name s.t. a^c and T « T(c), then F;c : T tbir(c) h a e{ c / x } > A; 

- let be lm(T).S e Input(Y(a)) such that T « [S], then T;a : T «r(a) h a e{ a / x ] > A. 

Proof. The proof is by induction on the derivation of the judgement F,x : T \- a et> A. 
The base case is when e = 0. In this case the hypothesis is F,x : T h„ 0> 0, T,x : 
T\-a: [end] and NoMark(r,jc : T), and the thesis is T;c : T U T(c) h„ 0> 0. Hence 
it is sufficient to show that T;c : T wr(c) h a : [end], which is immediate if a ^ c. On 
the other hand, if a = c then from the first hypothesis we have T(a) = [end] and from 
the second one we have T « [end], hence T = [end] = T fcfcl [end] as desired. For the 
inductive cases we proceed by a case analysis on the last rule that has been used to 
derive F,x : T h a e > A: 

(Type Spawn) In this case the hypothesis are Li,*: Ti tblT2,x : T2 \- a valfc = actor{ei};e2> 
Ai,A 2 ,{Z> : [Si WS 2 ]} and T = T\ l±ir 2 « (H wr 2 )(c). The first judgement comes 
from T\,x : T\,b : [Si] h e ei > Ai and r 2 ,JC : r2,i> : [S 2 ] h a e 2 i> A 2 . Observe that 
b is fresh, then b ^ c, then by induction we have Ti;c : T\ \±)Fi(c),b : [Si] \~b 
e x { c / x }> Ai andT 2 ; c : T 2 WT 2 (c), b : [S 2 ] h a e 2 {7-v} > A 2 . Then by (Type Spawn) 
we have F' h fl val^ = actor{ei{7. v }};e 2 {7. v }i> Ai,A 2 , {b : [Si WS 2 ]}, where T' = 
Ti;c : Ti WTi(c) W T 2 ;c : 7 2 l±)r 2 (c). Now observe that T' = (Fx ttir 2 );c : (T x W 
Ti (c)) W (J 2 wr 2 (c)) = (Ti tt)T 2 );c : (J W (Ti wr 2 )(c)) as desired. 



(Type Send) For simplicity let assume a single message parameter. In this case the 
hypothesis is F,x : T h„ u\m(u');e> A, which come from 

1. r,i:rha: [[S] \m{T').S a \, 

2. F,x:Thu: [S u .&* 6/ {*?m(7").S, lm(fi).Si}]; 

3. T' « (r,x : T)(u')\_ m , that is if u! = a then T' « [S a ] else if u' = u then 
7" « [S] else T' « T,x : T(u') and 

4. I> : T ; u : [5„.& iG/ {?m(r').5, ?m,(fj).S;}] ; a : [S a ] K, e> A. Notice thatx ^ a, 
then we have two subcases: 

(a) x ^ u, then T; w : [S„.& (G/ {?m(r').S, 7m; (7}). 5;}] ; a : [S a ],x : T h„ et> A 

(b) x = u and « ^ a, then T; a : [S a ],x : [5 M .& ;G /{?m(r').5, ?m,(7i).5,}] h„ 
e> A. 

Now, since x ^ a, but it might be the case that x = u and/or x = u'. Then we have 
to prove that F;c : T\&F(c) ^ a u{ € / x }lm(u'{ € / x });e{ c / x }t> A, which comes from 
the following judgements, implied by the enumeration above: 

- rha: [[S] I m(T').S a ], since x^a, hence Y;c : T l±ir(c) h a : T a , where 

• if a ^ c then T a = [[S] ! m{T').S a ] 

• if a = c, then T a = Tb) [[S] \m(T').S a ] together with the hypothesis T « [5] 

- T;c : T wr(c) h m{Vx} : 7L, where 

• if u ^ c,x, i.e. u{ c / x } = u, then T„ = [S u . &' €l {"lm(T').S, ?m i -(7;).S'j}] 

• if m = cor u =x, i.e., «{7. T } = c, then r„ = Tl+l [5„ .&* e/ {*?m(r / ).5, ?m,(7;).5 1 }], 
together with the hypothesis T « F(c) and T « [5] for c — a; 

- by induction we have 

• in the case 4. (a), i.e. x^ u,a, (T;u : T' u \a : [S a ]);c : T\+)(T;u : T' u ;a : [S a ])(c) h„ 
e{ c / x }> A where T u = [S u .Sc ieI {lm(T').S, ?m ( - 

• in the case 4.(b), i.e. x = u ^ a, (r;a : [5„]);c : T W (r;a : [5 a ])(c) h a 
ef/,} > A with T = [5„.&, G/ {?m(r').5, ?m, (7}). S/}] 

In both cases the environment is equal to 

(T;c : rar(c));« : [5„.&, e/ {?m(r).5, ?m i (7i).5 / }];a : [S a ] 

- let prove that 7" « (T;c : T tt)r(c))( M '{7 x }) [ m : 

• if u'{ c / x } = a then either u' = a, then T' « [S a ] by the hypothesis 3. 
above, or u' = x and a = c, and in this case the hypothesis 3. above gives 
V « I> : T(u'), that is T'«T. Moreover, from the hypothesis T « [S] 
and the fact that S « S a , we have T' « [S a ]- 

• if u'{ c / x } = u{ c / x } then either u' = u, then T' « [S] by the hypothesis 3. 
above, or u'{ c / x } = u{ c / x } = c and as in the previous item T' « T and 
by hypothesis T « [S], hence T' « [S]. 

• otherwise we have to show that T' « (T;c : T l+l F(c))(u'{ c / x }), that is 
either T' « (T;c : T l±ir(c))(c) or T « (T;c : T \£T(c))(u'). The first 
case come from the fact that by hypothesis 3. above we have T' « T, that 
together with T « T(c) gives what desired. The sencond case come from 
the fact that by hypothesis 3. above we have T' « r(w'), which is what 
desired since in this case u' ^ c. 

(Type Receive) In this case the hypothesis is T,x : T \- a react {miiyi) e,}, e /> 
& lG / (A,-, {yi : 7;}), which comes from (?) F,x : T h a : [& ie /{?m,(7i).5,'}] and (//) F,x : 
T;a: [Si] ,y~j : T, h a e,- > A,- for i G 7. We can assume that x ^ yi, hence from the 



last judgement we have F;a : [Sj],y~j : Tj,x : T h„ <?,■ > A;, which gives by induc- 
tive hypothesis T;a : [Sj]Ji : fee : T ttl (T;a : [S,-])(c) h a e,{7.J > A,-, that is T;c : 
rw(r)(c);fl : [S^y,-:?; h a e,-{7*}> A,- where S- = ^ tblTif c = a, otherwise S- = Sj. 
Now, from (;) and the hypothesis T « [Sj] of the lemma, we have T; c : Ttbl (T) (c) h 
a: [&,- e /{?m,-(7/).S-}], hence we concludeTjc: ri±)(r)(c) h„ react{m,(y,) e,{ c / x }}, e /[> 
&, G/ (A,-, {y t : 7}}) by (Type Receive). 



Lemma 18. Let beT = Ti,F\ O^,.^ \~F\ |F 2 [> Ai,A2 a derivable judgement. Then 

- For all u £ actors(Fi) U actors (F2), T(m) = T\{u) l±l T2 (w), hence T\(u) « r 2 (M) 
and T\ (u) « ^(w), i.e. the type of u has the same length in T\ and T2 

- For all u 6 actors(Fi), it holds Y\(u) «Y2{u) 

- For all u S actors^), it holds T2(u) « T\ (u) 

Subject Reduction Theorem If T h F > A and F — > F', then there exist T' such that 
T' h F' > A', with T' « r and A' « A. 

Proof. The proof is by induction on the derivation of F — > F'. We start with the base 
cases: 

(Ended) in this case the hypothesis are F h [a H» 0] a{0} > A and [a h-» 0] a{0} — >■ 0. 
From the first hypothesis we have that r h [a h> 0] and T h fl > A, hence A = 0, 
T h a : [end] and NoMark(r). Then T h o is also derivable, and by (Type Dead) 
we conclude T h > A as desired. 

(TOP Spawn) In this case the hypothesis are vala = actor{e};e' — > (va)([a M> 0]a{e}} | e')) 
and r h vala = actor{e};e' > A, which comes form T = Ti Wr2, A = Ai,A 2 ,a : 
[Si WS 2 ], ri,fl : [Si] h a e> Ai and T2,a : [S2] l~ e'> A2. Then we also have ri,a : 
[Si] I [a 1 ^ 0]a{e}> Ai, and by (Type Para), T' h [a 0}a{e} \ e'> A U A 2 
where P = T h a : [Si] ®T 2 ,a : [S 2 ] = Ti \t)T 2 ,a : [Si WS 2 ]. Then by (Type Res 
CONF) we conclude rh (va)([ai-» 0}a{e} \ e')> A. 

(Spawn) in this case the hypothesis are [b*->M]b{va\a = actor{e};e'} — > (va)([fo m> 
M]b{e'} I [a n> 0]a{e}) and T h [fe M>M]/?{vala = actor{e};e'}i> A, which comes 
form r h [fo n> M] and T val a = actorje}; e' > A. Then the proof is similar to the 
previous case. 

(Send) In this case the hypothesis are [a n- M]a{e} | [b >-> M']b{a\m(c);e'} — > 
[a^M-m(c)]a{e] \ [b<-+ M']b{e'} and [a ^M]a{e} \ [b^M']b{alm(c);e'}> 
A, which comes from T = Ti ,F\ Or 2 ,-F 2 , A = Ai, A2, Ti h [a i-> M] a{e} > Ai and 
r2 l~ [fe >-> M']b{a\m(c);e'}> A2. The last two judgements must have been de- 
rived from (/) n h [a i-> M] and (if) Ti h a e> Ai, resp. (iii) r2 h [i h-> M'} and 
(/v) T2 hfc a\m(c);e'> A?. 

From (iv)heknowthatr 2 r-i:[[S]!m(f).S 6 ],r 2 r-a:[S B .&; £/ { , ?/n(f).S, ?m,(7;).S,}], 
(*) T « T 2 (c) L, n and h fc e' > A 2 , then also T 2 h fo{e'} > A 2 , where Y' 2 = Y 2 ; a : 
[S K .&i € /{?m(f ).S, ?m,(f ; ).S,}] ; : [S fe ]. Notice that « T 2 . Moreover, from (iii) 
we also have T' 2 h [i 1-4 Af'] since Inputs(F' 2 (b)) = Inputs(F2(b)). Then by (Type 
Actor) we have r 2 h [6 i-> M'] ^{e'} > A 2 . 



Let show that from (i) we also have Yi \- [a t-> M ■ m(c)] by (Type Mailbox). 
From F2 h a : [S„ .&* e/ {*?m(f ).5, ?m i -(7/).5' i -}] we have 7m(T).S G Inputs(Y2(a)), 
then by LemmaP~8l?m(f l.S 6 Input s{Y\(a)). It is then sufficient to show that f < 
< Yi (c) [ m , that is if c = a then T « S else T « Y[ (c). From (*) above we know 
that if c = b then T « Y 2 (b),i£c = a then T « S else T « T 2 (c) . By Lemma[T8l 
Y 2 (c) « Ti(c) and ^(fr) « Y\ (b) hence we have T « Y{(c) [ m as desired. 
So we have F\ h [a ^M-m(c)], that together with (//) gives Ti h [at-^M-m(c)]a{e}> 
A] . Then by (Type Para) we have r' h [a i-> M ■ m(c)] a{e} | [b >-> M'] &{e'} > 
Ai,A2 where T' = Ti ©T 2 , i.e. T' « T as desired. 
(Receive) In this case the hypothesis are [a i— >M-mj(c)-M'} a{react{m,(f,) => c/}je/} — 
[a n- M'M'] a{cy{ c /*i}} w i tn J e ^ an ^ T h [a m> M-rrij(c)-M'] a{react{m,(x,) 
e i}r'e/} > A, which comes form (i) r h [a h- > M-nij(c)-M / ] and (//) T h„ react{m,(i,) => 
e* },£/[> A, where A = (A;, {x, : Ti}). From (;/) and j G 7 we have r h a : 
[&i(z{{7mj(Ti) .Si}} and T; a : [Sj},xj : 7} h fl e^-> Ay. Now, from (/) and ?m ; (f ; ).5 1 ,- G 
Input(Y(a)) we have f « T(c) |_ m , that is if c = a then T « Sj else T « Y(c). 
Let be r' = Y;a : [Sj], then we also have T « Y'(c) [ m . From T',Xj : Tj h„ e ; - > Ay 
and f « r'(c) |_m> by Substitution Lemma we have r';c : 7) WT'(c) h a ey{ e /f} > 
A y -. Let be T* = T';c : f, wr'(c). Note that Y* « T and from (i) we also have Y* h 
[ai-j-M-M'], than by (Type Actor) we conclude Y* h [ai-^M-M'] ha{e / { c 7.f}} [> 
Ay, with Aj « A. 

For the inductive cases we proceed by a case analysis on the last rule tha has been 
applied: 

(Par) In this case the hypothesis is F\ \ F 2 — > F[ \ F 2 since F\ — > F[, and r h F\ \ F 2 t> 
A. Hence A = Ai,A2, Y = Yi,Fi QY 2 ,F2, Yy h F\ > Ai and T2 h F2 1> A2. Then by 
inductive hypothesis we have Y\ h F/o Aj with r'j « Ti and Aj « Ai. Then by 
(Type Para) we have Y' h F{ F 2 > A' with A' = A'j , A 2 and Y' = Y\ , F{ Y 2 , F 2 
(note that we can guarantee that actors^') n actors^) = since we assumed that 
dynamically spawned actors have fresh names). Then observe that A' « A, hence 
it is sufficient to show that T' « Y, which comes oberving that Y\ (u) = Y\ (u) for 
all // ^ actors(Fi) while Y\ (u) « Y\ (u) for all u 6 actors(Fi) n zctors(F[). 

(Res) In this case the hypothesis is (va)F — ► (va)F' since F — > F', and Y h (va)F> 
A,a:T. The last judgement comes from Y,a : T h F> A, which gives, by inductive 
hypothesis, r',a :I'hF't> A' with r',a : T « Y,a : T and A' « A, and we 
conclude Y h (va)F' > A, a : T by (Type Res Conf). 

(STRUCT) In this case the hypothesis is F — > F' since F = F', F' — ► F" and F" = 
F'". This case comes by the fact that structural congruence preservs the typing. 

Lemma HT1 If h Pr> A and Pr — >* (va)([a i-> M]a{e} | F), then there exists T 
such that rh [ah M]a{e} and for any m(v) G M, there exists a matching input action 
lm{T).S that belongs to Inputs(Y(a)). 

Proof. (Sketch) Since actor initially have an empty mailbox, if m(v) G M, then it must 
bePr — >* {va'){[b^N]b{a\m{v)e b } \ [a ^ M']a{e'}) — >* (\a)([a\-> M]a{e} \ F). 
By Subject Reduction we know that the actor b{a \ m{v)\eb} is well typed, that is Y/, ha : 
[S a .&'{7m(T).S,..}], hence 7m(T).S e Inputs(Y b (a)).Now,if lm(T).S ^Inputs (Y {a)), 



it means that the input handler in a has been consumed by another output that would 
also require the type a : [S a .&'{lm(T).S, ..}], which is not possible since marking is 
linear. 

Lemma 19. 

Let be h Pro A with balanced(A) and Pr — ►* (va)([fli ^ Mi]a\{e\} \ ... \ [a k ^ 
Mk\ak{ek\) -f-^r. Then it is not possible that every actor body e; is a (stuck) input ex- 
pression. 

Proof. (Sketch) By Subject Reduction there exists A' such that 

h (va)([fli M- M\]ai{e\} | ... | [cik M> Mk] ak{ek}) > A', hence there exist Ti, ...,r^ 
such that ITi . . . ©r* C A' and r, h [a; n> M,] a,{e,} > A; for i = l,..,k. By contradic- 
tion, assume that every actor body e, is a (stuck) input expression. Then we have that for 
all i = l,..,k, r,- h a,- : [8i{!m'p(x' e ) .S' e }]. Moreover, since the initial system is balanced 
and since by hypothesis no matching message is already in the mailbox, for any actor 
a, there must be an actor aj whose body sends a matching message, i.e. ej must contain 
the sub-expression a,- ! m' e (c) for some message me. However, this is not possible since 
the typing of (the output action of) aj depends on the (continuation of the input) type of 
a, and so on yielding a cyclic dependence between a set of actors which would require 
recursive typing. 

Safety Theorem Let be h Pro A with balanced(A). If Pr — >* F then either F = 
or F — > F' for some F'. 

Proof. (Sketch) Let prove it by contradiction: assume that there exists a configuration 
F* ^ such that F* h We can assume F* = (va)([ai n> Mi]a\{e\} \ ... \ [a& i-> 
Mk]ak{ek}) with {ai, ...,#&} C a. Then by Subject Reduction there exists A' such that 
\-F*> A', with A' « A and balanced (A'). Then we also have that there exist T\, ...,L(. 
such that Ti © . . . Tjt C A' and r, h [a,- M> M,] a,{e,} > A,- for i = 1 , .., k. We have one 
of the following cases: 

- for all ; e {1, ..,£}, if e,- = aj \ m(c);e then we have that T, h a ; - : [S u .&* {Tm(T).S , ..}] 
and by definition of we have that Tj(a) = [S' ll .&{ r !m(f).S 1 ..}] for some S' u « S u , 
that is the input handler of the message m is still in the body of the actor aj, i.e. 
ej ^ 0, that is e {fli, ...,«<;} and F* — > contradicting the assumption. 

- for all i e {l,..,k}, if e; =0we have two cases: if M, = then the (Ended) 
reduction rule applies, giving a contradiction. On the other hand, let be M, ^ 0, 
from e,- = and the typing we have T,- h a, : [end], but by Lemma [TTI and M; 7^ 
we have T l/a, : [end], giving the desired contradiction. 

- If an actor body starts with the spawning of a new actor, then trivially F* — 
giving the contradiction. 

- Finally, we have the case where every actor body e, starts with an input expression, 
which is not possible by Lemma [T9l 



